To: "Geoff Oltmans" <geoff@sprynet.com>
Subject: Re: RonsWeek'n'ADAM - Oct 5, 1997

Ron:
Well, I'm not absolutely certain, but I think there are ways to
get around that with judicious use of .REL files. CP/M 3.0, I 
believe, does a better job.

Geoff:
>I would say that TDOS lives up to all of it's promises. However
it might be nice to have an operating system that supports, for 
example, TSRs (which TDOS doesn't), and modular device drivers 
instead of having a kernel that is patched for this thing or 
that).  Simply put, spaghetti code means code that is cobbled 
together without a plan, or patched too much, or code that makes 
no sense to anyone but its author. There are a variety of 
explanations, but I think these three are the most common.

Ron:
Sounds like a pretty tall order to me. It assumes that everyone
is on the same wave length, and if they're all on the same wave-
length, then chances are their creativity has gone down the tube
to some extent at least.

The programs I had most fun writing were the ones that were
cobbled together without a plan. To me "plan" is a 4 letter word.
But you're absolutely right of course.


Geoff:
 2) What activities are included in the process of managing or
    maintaining source code, and why are they important, given
    that the product is out there and serving?

The most common way of doing this is to heavily comment the
source code so that some other person can understand how it 
works. This is especially helpful if trying to write a program 
for an operating system.  Other ways my programming teachers 
taught me were Flowcharting and Pseudocode 

Ron:
Yup. Sometimes the problem here is that people are too close to
their work, and fail to understand that the comments might not 
make sense to somebody who wasn't there at the time the code was 
written. Comments of necessity have to be short and to the point.
The shorter they get, the greater the liklihood of them being 
misinterpreted.

Geoff:
Well, modular code is something you can add bits to and remove
(i.e. device drivers) without having to recompile that piece of
software. For example, you can't remove hard disk support from 
TDOS unless you install an entirely different revision of TDOS. 
I think this could be extremely helpful. The other is a common 
set of routines that are used by several programs (like sound 
or graphics routines). The problem with this approach becomes 
painfully obvious for anyone that tries to compile a
program in UNIX or a UNIX variant (like Linux or FreeBSD or
Solaris, etc.) when you try to compile something that you don't 
have all the pieces for. The compiler can crap out for no appar-
ent reason at all. This happened several times to me when trying 
to compile ADAMEM until I realized I was trying to compile with 
ZLIB support (zlib allows you to run "crunched" software without 
having to "uncrunch", it does this automatically), and I didn't 
have ZLIB installed. I don't think this type of radical modular 
approach is terribly practical for the ADAM, simply because the 
ADAM isn't a very large platform.

Ron:
Understood, thanks. At the time ADAM software was actively being
written,there was precious little co-operation between developers
on anything.  I don't think it would have been possible then to 
reach any sort of common understanding on the way resources were 
used. And users didn't understand enough about software available 
to exercise any kind of buying pressure on the developer commun-
ity. Bad scene all around.

Geoff:
I think a certain degree of backward compatibility is important.
However if something new comes along with more potential and bet-
ter comes along, who really cares if program 'X' when a perfectly 
suitable replacement exists that will work? After all, we're 
using a computer which is a dead platform...why not play with it 
a bit?

Ron:
Agreed. Besides I have four of them. Once can stay 'traditional',
and that would answer the problem of backward compatibility. Most 
of us have more than one these days.

Geoff:
Insofar as providing additional memory is concerned, I can see
no problem with setting aside a 64k memory expander as a hardware
requirement for the new operating system. Seems like a small
price to pay.
I thought you were a staunch believer in backward compatibility?
What about all those people who don't have memory expanders?
Seriously, I'm just poking at you. :)

Ron:
Well yes, but I want my cake and eat it too.  :)

Geoff:
Amen...perhaps we'll never see another version of EOS come
along. If so, why do we have to use the jump table at all for 
accessing BIOS routines?

Ron:
Exactly. This is what was given to me as the reason for NOT
making direct BIOS calls. What is your program going to do if 
the location of that routine changes with a new version of the 
OS? But if, as you say, there is no new version of the OS, 
what's the problem.... other than it countenances bad programm-
ing habits which might get you in trouble on another platform.

****************************************************************

Appreciate the comments Geoff. Thanks.

Ron Mitchell





Last page.  Enter command or <CR> to continue !